The present application relates generally to an improved data processing apparatus and method and more specifically to mechanisms for identity propagation through application layers using contextual mapping and planted values.
Modern information processing environments are experiencing a trend from the traditional client-server model to an application-server model. While the client-server model categorizes information resources as services to a client, an application-based architecture allows each application to perform specific and/or specialized portions of processing before handing a transaction or data stream off to a successive processing tier. An application-server model may exhibit a so-called multi tier arrangement or architecture. In a multi-tier arrangement, each tier is responsible for performing a particular aspect of processing. Tiers communicate by passing or transmitting data, often according to a predetermined protocol or data structure. A business transaction is therefore passed between tiers, which may be successive layers or nodes in the processing stream. According, each tier, or “layer,” receives a transaction from a preceding layer.
Each tier/layer may perform particular functions, such as database queries, XML parsing, tunneling, protocol mapping, network transport, or GUI (graphical user interface) operations, for example. At each tier, attributes of the transaction or data stream are communicated to the next tier. However, certain attributes may be suppressed or omitted if those attributes are deemed unnecessary at the successive tier. Therefore, in a multi-tier arrangement, while scaling, information scope, and function consolidation may be improved, certain attributes of the transaction or information stream may not be propagated as readily as in conventional client server arrangements. Operations or functions that expect certain attributes available at a particular layer may encounter difficulty (i.e. unavailability) if they rely on that attribute.
One set of examples in which information is lost between operations performed at different tiers/layers of an application-server model based system are security functions, such as audit trails or the like. Almost all security functions are based on a credential. Audit trails key on the identity of a user or client machine (e.g., produce a report showing all activity performed by the user or client machine), access control keys on the identity (e.g., user X should not be allowed to access data Y), and the like.
In some cases, the security function is provided by the same layer that provides the identity layer. For example, when a user connects directly to a database there is a user name that is used to log onto the database. The same user name is also used to define privileges in the database system and the same name appears in the audit trail generated by audit security mechanisms. This is true regardless of whether the database itself is the system enforcing access control rules and performing the auditing or an external security system performs these functions. Because the user name used for the security functions is managed by the database security tier, it is meaningful to the security operator, who defines privileges or reviews the audit trail.
However, there are cases in which the security function is provided at one tier while the identity is provided by another tier. A very common case involves application servers that use a database as their back-end. In such cases, the application is the tier responsible for managing the identities. A user logs onto the application and provides, for example, a user name and a password. The application will typically utilize a database on the back-end to store and manage the data used or accessed via the application. The application server uses connections to the database.
In client/server architectures there is usually a connection to the database for every user and often the credential used to log onto the application is also used to generate the connection to the database, i.e. for every user of the application there is also a user at the database level. However, in the much more common application-server based architecture, this is not true. Instead, the application server maintains a pool of connections to the database. These connections are all created when the application server first starts and they all use a single functional account, i.e. the connections are all associated with a single functional identifier for the application front-end without distinguishing between users of the application front-end. These connections are reused by all user sessions, i.e. multiplexing is used. That is, when a user logs onto the application front-end, a session is created with the application front-end and the application front-end gets a connection from the database's connection pool and assigns it to the session. When the session ends, the connection is released back to the pool and may be reused by the application front-end for another session. This is done to increase performance and reduce overhead.
From a security point of view, however, this connection pool mechanism causes a serious problem. The identity of the user is lost from the viewpoint of the database layer, i.e. the user identity is not passed to the database back-end, and only exists at the application layer, i.e. at the application front-end. For example, if one were to look at an audit trail produced by an audit mechanism operating at the database layer, such as an audit mechanism of the database itself or a Database Activity Monitoring (DAM) system, then all activity is shown to have been performed by the entity logged onto the database, i.e. the functional account of the application which is identified by a functional identifier. However, what a human auditor, or automated security mechanism wants to be able to see in the audit trail is which end-user of the application layer caused the particular database query to be issued and therefore, which user was able to access certain sensitive data. The audit trail provides little useful information from a security point of view because the “real identity” of the end-user is not propagated through the application layer. While an application layer audit trail could be used, it is often a data-level audit trail that is required for particular security mechanisms and this can only be performed at the database layer.